1. Field of the Invention
The present invention relates to a client server system which executes an application utilizing distributed objects.
2. Description of the Related Art
Recently, application forms based on Web browsers have been rapidly increasing, and the distributed object use has largely changed. Specifically, the method of creating an object on a server directly from a client was previously dominant, but, at present, an application model has been spread in which objects are created on other servers using the distributed object technology on a Web server or a Web application server. Actual implementation examples include the combination of ASP and MTS (trademarks of Microsoft Corporation), or the combination of WebSphere and ComponentBroker (trademarks of IBM Corp.).
Distributed objects are made from data, applications, or processes and the like, and can be accessed from any place in a network and used for tasks. More specifically, they enable an object oriented method call to be remotely operated, and constructed as middleware implementing an object-oriented programming interface in the upper layer of the socket level. In the distributed object programming technique, an object in a remote machine appears in the local machine as if it were a mirage, and the remote object can be freely manipulated by operating on it. The distributed object mirage is called a proxy object (agent object), which is apparently the same as the object on the remote machine (actual object: remote object), but it exists as an agent rather than a real object, and the first access point for the client is a Web server instead of the actual server.
When the distributed object environment is used, the object creation process is the highest software cost. As a matter of fact, the creation process of the remote object of the distributed object is known for taking longer than any other process, and the key to shortening overall response time is how fast the object creation process is made. If the object pooling technique in a database management system, as described in Published Unexamined Japanese Patent Application No. 10-11339, is redirected to create objects prior to the access from a client, and an object can be passed from the pool when the object creation is requested from the client, then the response time can be shortened.
However, since the existing pooling technique, as described in the above-mentioned publication, is a mechanism in which, upon receipt of the request from a client, those which have already been used are pooled, the pooling mechanism is not effective when starting up the server, and thus it is difficult to achieve the determined response time. Further, in a database system in which the request from a client is clear, as in the existing technique, it is possible to simply create a predetermined object at the initialization. However, in an environment in which the object to be created is not known until the time of execution, such as a distributed object rather than the predetermined object as in the database, a sufficient effect cannot be obtained by only implementing the existing pooling mechanism.
Further, in the conventional object pool, the pooling is performed at the request of releasing to a created object, and then, an object in the pool is assigned to the client at the request of creation to the same class, thereby increasing the performance, but valid objects are not always pooled. Specifically, if proxy objects are pooled in an application utilizing distributed objects, proxy objects which have already become invalid on the server may be assigned at the request of object creation from the client. If such inconsistency occurs, an error is produced, for instance, when the client uses an object which has already become invalid, and the object pool becomes meaningless. It is possible to keep the validity of an object by setting an expiration date for each object, and automatically deleting objects which are not used for a certain period of time, but, with this function, there still remains a risk of deleting valid objects from the pool.
There is also an implementation form of an object pool which takes the above problems into consideration to provide a function in which a specified method is called out when releasing an object, and in this method, control can be made as to whether or not the object can be pooled according to the logic implemented by the user. This method is fully flexible in that the user can freely control the movement of an object. However, the burden on the user is much larger, and the process is always routed through that logic which increases the amount of processing. Furthermore, since behavior at the time of using the pool is built in as the implementation of objects, it is difficult to control the operation when no object exists, such as the time of starting up an application.